SharePoint 2010 : Introducing Records Management and Information Management Policies

• Health Insurance Portability and Accountability Act (HIPPA) Requires organizations that have access to personal health information to adopt security policies to safeguard the confidentiality of the data. Organizations must also monitor and control access to the data and maintain an audit trail available to regulators.

• Sarbanes-Oxley Act (SOX) Applies to publicly traded companies and requires that companies put in place extensive policies and procedures to control their financial information and to prevent fraud. It also requires that executives certify the validity of company financial statements and that independent auditors verify the financial controls put in place.

In addition to the rules and regulations that organizations must comply with for legal reasons, companies have found that defensive business practices also call for good data management to protect the company during litigation. Companies are often required to produce copies of documents and files deemed to be relevant to a lawsuit or prosecution. In some cases in which companies could not produce the requested documents, courts have ruled that documents that are not available are assumed to support the plaintiff’s arguments. Organizations cannot afford to lose control of critical documents and e-mail messages.

1. What Is Records Management?

Records management enables a company to effectively manage a content item, or record, from inception to disposal in accordance with applicable laws, such as the federal regulations mentioned previously. A record is a physical or electronic document, an e-mail message, or some other form of digital information, such as an instant message transcript, that serves as evidence of an activity or transaction performed by the organization.

Records management is the process by which an organization defines what type of information it needs to classify as a record, how long it needs to retain the information, and how it will manage the information throughout its life cycle. Part of the challenge of records management is to identify and track information items that are legally or economically vital to the business. For example, an e-mail message that contains some reference to financial information about the company or about a client might well be considered a record. The other part of the challenge is to filter and purge items that do not need to be stored as records. As an example, an exchange of e-mail messages in which two employees of an organization decide where to have lunch might not be considered record material.

Although setting a policy that declares everything to be a record might seem to be a safe approach for an organization, this policy could be almost as harmful as not declaring any content item a record. For example, if a legal action requires that a company deliver the approximately one hundred e-mail records that pertain to a court case, and the best that the company’s IT department can do is provide the 10,000 e-mail messages sent within a specific time frame, then the court may rule that delivering the relevant items buried within a mass of irrelevant data to be a form of obstruction. An additional benefit can be obtained from creating policies that determine what a company record is, rather than trying to store everything as a record—because records are stored based on content types, narrowing the definition of what constitutes a record can improve the ability of users to perform targeted searches that avoid returning irrelevant data.

A well-designed records management plan is essential for data retention policies to mesh with actual data management processes. For example, if a company’s retention policy specifies that a document should be purged and destroyed after one year, then backups should be designed so that no backup more than a year old has a copy of the file on it. On the other hand, a retention policy that dictates that a document must be readily available for review for a period of three years requires that a live copy of any document be kept in a storage location from which it can be pulled without restoring it from backup. These types of organization-specific requirements dictate a need for every company to not only develop the appropriate policies but to implement and enforce those policies as well. There have been cases in which organizations have not followed their own policies and were required to retrieve specific data from archival backups and restore it onto their network, which is generally a very time-consuming and costly process.

A records management plan should contain the following elements.

• A compliance requirements document that defines the policies the organization must implement to ensure compliance with legal and regulatory requirements, along with the practices that employees must adhere to in accordance with the policies

• A chart that indicates who will be responsible for the different roles that must be filled in the records management process

• A file plan that identifies which types of information are considered records, where they are stored, the permissions and policies that govern them while they are active, and how and when to dispose of records

2. Compliance Requirements Document

The compliance requirements document explains the purpose of a compliance program and its benefits together with its essential components. It identifies the legal or business criteria to which the compliance plan must adhere and the metrics or other objective criteria that will be used to measure the effectiveness of the compliance plan. The compliance requirements document includes the formal policies that represent the organization’s internal statement of the regulatory rules it must follow.

The compliance requirements document should also include specifications for ongoing training for employees at all levels and guidelines for the roles and involvement of senior management in the compliance process. Although it may not be practical for every organization, a formal compliance audit should also be carried out at regular intervals to ensure that the records management plan is meeting its objectives.

3. Records Management Roles

When developing the records management plan, it is important to consider who is responsible for the various roles that are involved in the creation and implementation of the plan. Since SharePoint 2010 is a content-rich application, some of these roles will include the SharePoint administrator, content managers, records managers, and compliance officers.

3.1. SharePoint Administrator

Administrators are responsible for the installation and configuration of the SharePoint 2010 servers that provide records management services to the enterprise. They create the Web applications and the Records Center site and configure the connection to the official file that lets users submit documents to the records center.

3.2. Compliance Officers

Compliance officers are usually associated with an organization’s legal department and are often lawyers. They are responsible for understanding and interpreting the regulations and rules that the organization must follow. They develop the formal compliance policies that the company will implement and, as a result, they are the primary authors of the compliance requirements document and perform internal monitoring and auditing to ensure that the organization closely follows the records management plan.

3.3. Records Managers

Records managers are responsible for developing the file plan that applies the compliance requirements document to the different types of information items that the organization produces. The records managers may also be members of the organization’s legal department or may be senior administrative staff members who have a thorough understanding of the organization’s business practices and workflow. After the SharePoint administrators have created the Records Center site, records managers are in charge of configuring the document libraries and retention rules in the site. Records managers should be consulted at all points in the design of the records management system

3.4. Content Managers

Content managers work on the teams that create information items that will be designated as records. If necessary, the content managers configure team sites with the appropriate content types and workflows to facilitate the effective and efficient categorization of documents so that they can be routed to the appropriate location.

3.5. Information Workers

Information workers are the employees in an organization who create new documents and e-mail messages that need to be classified and routed to the records center for safeguarding. The goal of a reliable records management system should be to make it relatively easy for information workers to classify information accurately, or even automatically, as it is produced.

4. The File Plan

The file plan is a written document or set of documents that lists all of the types of information that an organization receives or produces and how each one should be classified and handled. Some information will be classified as a record when it is created, other information will be treated as a record only when it reaches a certain stage in its life cycle, and then there will be information that is either temporary or unimportant enough that it is not considered a type of record. The criteria used to classify a record will come from the organization’s compliance requirements document produced by the compliance officer.

Note:

As part of your effort to train and educate your end users about how to use SharePoint Technologies, be sure to educate them about the file plan and any information management policies that apply to them. Users need to know when a document or record moves from being unofficial communication to being official communication, and they also need to know your company’s policy to properly consume, store, and dispose of official records.

Although the details of what enters into the file plan will depend on the type of information that your organization is managing, there are usually some common elements in most plans. As shown in Table 1, these elements include a list of record types and the key information that must be associated with each type to ensure that it is filed properly. After an information item is classified as a record, it can be copied or moved into a SharePoint 2010 site based on the Records Center site template. This site serves as the storage area for both active and inactive documents that must be readily available as either an information resource for staff or as evidentiary material in litigation. Active documents are those that are still in use as part of a project or an ongoing e-mail discussion. These documents may continue to be updated over time, and new versions will be submitted to the repository as they are generated. The file plan will specify whether older versions of the same document are retained and for how long. Inactive documents are those that have reached their final version or have been submitted formally to an agency. Although employees will probably not generate any further versions of the document, the last version must be retained as an official record of the transaction.

It is important to distinguish between documents that are retained as records and those that are retained in an archive. Archived information is not classified as a record after the period for which it needs to be retained as a record has expired. At that point, the information is usually transferred to tape or printed out and placed in long-term storage with the expectation that it will be kept mainly for historical purposes. Archived data is generally not readily available for search and retrieval and it is not expected to be required for current research or legal discovery. But keep in mind that the legal discovery process can request any information deemed appropriate for the matter at hand, another reason to make sure expired data is properly archived.

In Table 2, you can see an example of a standard file plan filled out for several record types in an organization. As you can see, different document types have different record management requirements. For example, financial statements will be kept indefinitely in archival storage because of their historical value to the company, but e-mail correspondence is considered too voluminous and of too little value to archive in the long term.

Normally, your organization’s legal department provides you with the storage and archive requirements for any documents in SharePoint that have legal requirements associated with them or that are considered important enough to require some form of records management.

5. What Are Information Management Policies?

Information management policies are sets of rules governing the automated management of documents, such as how long a file should be retained or which actions on the file should be audited. Each rule in a policy is called a policy feature. Policies in a records management system are configured by records managers to reflect the file plan requirements. The value of storing files in separate document libraries becomes obvious when you start designing the information management policies that you will apply to each library.

There are two recommended approaches for implementing policies in the repository: (1) create individual policies for each document library if the requirements are unique to the content in each library, or (2) create site collection policies to cover an entire set of record types and apply them to several document libraries as needed. You can either apply one policy for the entire document library, or if you configure the document library to allow multiple content types, then you can apply a separate policy to each content type. Figure 1 shows the four features available when defining an information management policy.

After creating a policy, you implement it by associating it with a site collection, content type, list, or library. This association to a content type, list, or library can be accomplished using one of the three following methods.

• Site Collection Policy Associate the policy features with a site collection policy and then associate that policy with a content type, list, or library.

• Content Type Policy Associate a set of policy features directly with a content type and then use that content type in one or more lists or libraries.

• List or Library Policy Associate a set of policy features directly with a list or library. However, you can only use this method when the library or list is not using more than one content type.

Note:

A policy feature might use one or more policy resources, which are programs that provide functionality to a policy feature. For example, a custom policy resource for the barcode policy feature could be used to generate a unique barcode value for a document.

6. Planning Document Policies

The use of policies can be simplified by planning how and where they will be used. This can be accomplished by first determining your organization-wide policy needs and then designing your site collection policies to meet those needs and distribute those policies for use as site collection policies for all relevant site collections. If any policy requires custom policy features or resources, those features and resources have to be installed and enabled on all server farms using that solution.

7. Policy Metadata

Policies often require the use of additional document properties or metadata. It is important to create consistent metadata properties that can be used throughout your entire farm. SharePoint 2010 introduces a service application called MMS (Managed Metadata Service) that is used to create enterprise-wide content types and metadata. This service application will host a Web application with a site collection that you can use to create your farm level content types and metadata properties, which eliminates the need to create them as a feature and deploy them to each site collection, as was the case in Microsoft SharePoint Server 2007. All Web applications that are associated with the Managed Metadata Service can consume any content type as well as metadata from the MMS service application.

For instance, when you configure the retention period of a document, you may need to use a SharePoint-provided date property or create a custom date property that will be used to determine when an action is performed on that document.